Integrity verification method, apparatus, and system and device for data in a blockchain-type ledger

ABSTRACT

Computer-implemented methods, non-transitory, computer-readable media, and computer-implemented systems for data verification are provided. When a blockchain-type ledger needs to be verified, integrity verification can be first performed on block headers in a coordinator node only. After the verification succeeds, a second verification instruction can be further distributed to data nodes, so that the data nodes perform data block internal verification in parallel.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/815,902, now allowed, filed on Mar. 11, 2020, which is a continuationof PCT Application No. PCT/CN2020/071219, filed on Jan. 9, 2020, whichclaims priority to Chinese Patent Application No. 201910273141.3, filedon Apr. 4, 2019, and each application is hereby incorporated byreference in its entirety.

TECHNICAL FIELD

Implementations of the present specification relate to the field ofinformation technologies, and in particular, to data verificationmethods, apparatuses, and systems, and devices.

BACKGROUND

Each data block needs to be verified in a block generation sequence, soas to complete integrity verification on a partial or fullblockchain-type ledger that stores data based on a blockchain datastructure (e.g., in a form of a blockchain). However, when ablockchain-type ledger to be verified has many data blocks and many datarecords in the data blocks, verification efficiency is relatively low.

Based on this, a more efficient data verification method is needed for ablockchain-type ledger.

SUMMARY

An objective of implementations of the present application is to providemethods for implementing efficient data verification in ablockchain-type ledger.

To alleviate the previous technical problem, the implementations of thepresent application are implemented as follows:

A data verification method is applied to a database system that storesblockchain-type ledgers in a centralized manner. The database systemincludes a coordinator node and data nodes, and the method includes thefollowing: receiving, by the coordinator node, a first verificationinstruction, and determining a target ledger that is to be verified, andperforming block header integrity verification on block headers of datablocks in the target ledger based on block header information stored inthe coordinator node, where the target ledger includes a partial ledgeror a full ledger; if the block header integrity verification succeeds,determining a target data node corresponding to each data block in thetarget ledger based on routing information between a data block and adata node stored in the coordinator node; sending a second verificationinstruction to the target data node, where the second verificationinstruction includes a data block identifier; receiving, by the datanode, the second verification instruction, performing block bodyintegrity verification on a data block corresponding to the data blockidentifier, generating a verification result, and returning theverification result to the coordinator node; and receiving, by thecoordinator node, the verification result, and determining integrity ofthe target ledger; where in the blockchain-type ledgers, a data blockincludes a block header used to store metadata and a block body used tostore a data record; and except an initial data block, each data blockincludes at least one data record and includes its own block hash valuethat is determined by both the data record included in the data blockand a hash value of a previous data block, and block heights of datablocks are increased monotonically based on a block generation timesequence.

A data verification system is applied to a database system that storesblockchain-type ledgers in a centralized manner. The database systemincludes a coordinator node and data nodes, where the coordinator nodereceives a first verification instruction, and determines a targetledger that is to be verified, and performs block header integrityverification on block headers of data blocks in the target ledger basedon block header information stored in the coordinator node, where thetarget ledger includes a partial ledger or a full ledger; if the blockheader integrity verification succeeds, the coordinator node determinesa target data node corresponding to each data block in the target ledgerbased on routing information between a data block and a data node storedin the coordinator node; the coordinator node sends a secondverification instruction to the target data node, where the secondverification instruction includes a data block identifier; the data nodereceives the second verification instruction, performs block bodyintegrity verification on a data block corresponding to the data blockidentifier, generates a verification result, and returns theverification result to the coordinator node; and the coordinator nodereceives the verification result, and determines integrity of the targetledger; where in the blockchain-type ledgers, a data block includes ablock header used to store metadata and a block body used to store adata record; and except an initial data block, each data block includesat least one data record and includes its own block hash value that isdetermined by both the data record included in the data block and a hashvalue of a previous data block, and block heights of data blocks areincreased monotonically based on a block generation time sequence.

A data verification method is applied to a coordinator node in adatabase system that stores blockchain-type ledgers in a centralizedmanner. The method includes: receiving a first verification instruction,and determining a target ledger that is to be verified, and performingblock header integrity verification on block headers of data blocks inthe target ledger based on block header information stored in thecoordinator node, where the target ledger includes a partial ledger or afull ledger; if the block header integrity verification succeeds,determining a target data node corresponding to each data block in thetarget ledger based on routing information between a data block and adata node stored in the coordinator node; sending a second verificationinstruction to the target data node, where the second verificationinstruction includes a data block identifier; and receiving averification result returned by the target data node for the data block,and determining integrity of the target ledger based on the verificationresult.

A data verification apparatus is applied to a coordinator node in adatabase system that stores blockchain-type ledgers in a centralizedmanner. The apparatus includes: a block header verification module,configured to receive a first verification instruction, and determine atarget ledger that is to be verified, and perform block header integrityverification on block headers of data blocks in the target ledger basedon block header information stored in the coordinator node, where thetarget ledger includes a partial ledger or a full ledger; a determiningmodule, configured to, if the block header integrity verificationsucceeds, determine a target data node corresponding to each data blockin the target ledger based on routing information between a data blockand a data node stored in the coordinator node; a sending module,configured to send a second verification instruction to the target datanode, where the second verification instruction includes a data blockidentifier; and a receiving module, configured to receive a verificationresult returned by the target data node for the data block, anddetermine integrity of the target ledger based on the verificationresult.

According to the solutions provided in the implementations of thepresent specification, when a blockchain-type ledger needs to beverified, integrity verification can be first performed on block headersin a coordinator node only, and after the verification succeeds, asecond verification instruction can be further distributed to datanodes, so that the data nodes perform data block internal verificationin parallel, thereby greatly improving verification efficiency.

It should be understood that the previous general description and thefollowing detailed description are merely exemplary and illustrative,and cannot limit the implementations of the present specification.

In addition, there is no need for any implementation of the presentspecification to achieve full effects described above.

BRIEF DESCRIPTION OF DRAWINGS

To describe the technical solutions in the implementations of thepresent specification or in the existing technology more clearly, thefollowing briefly describes the accompanying drawings needed fordescribing the implementations or the existing technology. Clearly, theaccompanying drawings in the following description merely show someimplementations of the present specification, and a person of ordinaryskill in the art can still derive other drawings from these accompanyingdrawings.

FIG. 1 is a schematic diagram illustrating a system architectureinvolved in an implementation of the present specification;

FIG. 2 is a schematic diagram illustrating a block header, according toan implementation of the present specification;

FIG. 3 is a schematic flowchart illustrating a data verification methodapplied to a database system, according to an implementation of thepresent specification;

FIG. 4 is a schematic flowchart illustrating a data verification methodapplied to a coordinator node, according to an implementation of thepresent specification;

FIG. 5 is a schematic structural diagram illustrating a dataverification apparatus applied to a coordinator node, according to animplementation of the present specification; and

FIG. 6 is a schematic structural diagram illustrating a device forconfiguring a method in an implementation of the present specification.

DESCRIPTION OF IMPLEMENTATIONS

To make a person skilled in the art better understand the technicalsolutions in the implementations of the present specification, thefollowing describes in detail the technical solutions in theimplementations of the present specification with reference to theaccompanying drawings in the implementations of the presentspecification. Clearly, the described implementations are merely somebut not all of the implementations of the present specification. Allother implementations obtained by a person of ordinary skill in the artbased on the implementations of the present specification shall fallwithin the protection scope of the present specification.

The technical solutions provided in the implementations of the presentspecification are described in detail below with reference to theaccompanying drawings.

First, notably, a database system in the present specification providesa data service in a centralized manner. In a current serverarchitecture, a database server can directly interconnect to a clientdevice of an individual user; or some application servers caninterconnect to client devices of individual users, while a databaseserver interconnects to the application servers. In the database systeminvolved in the implementation of the present specification, onecoordinator node can correspond to multiple data nodes. FIG. 1 is aschematic diagram illustrating a system architecture involved in theimplementation of the present specification.

A data block can be generated in advance in the centralized databasesystem in the implementation of the present specification in thefollowing way:

A data record to be stored is received, and a hash value of each datarecord is determined. The data record to be stored can be variousconsumption records of a client device of an individual user, or can bea service result, an intermediate state, or an operation record, etc.that is generated when an application server executes service logicbased on an instruction of the user. A specific service scenario caninclude a consumption record, an audit log, a supply chain, a governmentsupervision record, and a medical record, etc.

When a predetermined block generation condition is reached, each datarecord to be written into a data block is determined and the Nth datablock that includes a hash value of the data block and the data recordis generated.

The predetermined block generation condition includes the following: aquantity of data records to be stored reaches a quantity threshold, forexample, one new data block is generated each time a quantity ofreceived data records reaches 1000, and the 1000 data records arewritten into the block; or a time interval from a previous blockgeneration moment reaches a time threshold, for example, one new datablock is generated every 5 minutes, and data records received in the 5minutes are written into the block.

N here refers to a sequence number of a data block. In other words, inthe implementation of the present specification, the data blocks arearranged in a blockchain-based form in a block generation time sequence,and have a strong time sequence characteristic. Block heights of thedata blocks are increased monotonically based on the block generationtime sequence. A block height can be a sequence number. In this case, ablock height of the Nth data block is N. The block height can also begenerated by using another method.

When N=1, the data block is an initial data block. A hash value and ablock height of the initial data block are given based on apredetermined method. For example, if the initial data block does notinclude a data record, the hash value is any given hash value, and theblock height blknum is equal to 0. For another example, a triggercondition for generating the initial data block is the same as a triggercondition for another data block, but the hash value of the initial datablock is determined by performing a hash operation on all content in theinitial data block.

When N>1, because content and a hash value of a previous data block arealready determined, a hash value of a current data block (the Nth datablock) can be generated based on the hash value of the previous datablock (that is, the (N−1)th data block). For example, in a feasiblemethod, a hash value of each data record to be written into the Nth datablock is determined, and a Merkle tree is generated based on a sequenceof the data records in the block. Then, a root hash value of the Merkletree is combined with the hash value of the previous data block togenerate the hash value of the current block by using a hash algorithmagain. In addition, the hash value of the current block can further begenerated based on the root hash value of the Merkle tree and some othermetadata (for example, a version number, a generation timestamp of thedata block, or a parent data block hash).

For another example, combination can be performed based on a sequence ofthe data records in the block and a hash operation can be performed toobtain a hash value of the overall data records. Then, the hash value ofthe previous data block is combined with the hash value of the overalldata records, and a hash operation is performed on a string obtainedthrough the combination to generate the hash value of the data block.

Each data block includes a block header used to store metadata and ablock body used to store a data record. The block header in the datablock can be used to store, for example, a parent hash, a block hashvalue of the data block, a version number, a root hash of a data record,and a timestamp, etc. FIG. 2 is a schematic diagram illustrating a blockheader, according to an implementation of the present specification.Certainly, a format of the block header can be customized based on aservice requirement, and can further include some other information, forexample, a status array used to describe a status of a data record. Theblock body is used to store plaintext of a data record or a hash valueof a data record.

In the previously described data block generation method, each datablock can be determined by using a hash value, and the hash value of thedata block can be determined by content and a sequence of data recordsin the data block and the hash value of the previous data block. A usercan initiate verification at any time based on a hash value of a datablock. Modification to any content in the data block (includingmodification to content or a sequence of data records in the data block)causes inconsistency between a hash value of the data block that iscalculated during verification and a hash value obtained when the datablock is generated. Consequently, the verification fails andtamper-resistance can be implemented in the centralized manner.

Notably, the previously described data block generation can beimplemented in or not in the coordinator node. For example, the databasesystem can further include another service node, which is specificallyconfigured to handle data block generation, so as to implement servicedecoupling. Once a data block is generated, the service node sends thedata block to the coordinator node.

After obtaining the data block, the coordinator node in the databasesystem needs to store the data block. An implementation of the presentspecification provides a data storage method applied to a databasesystem. The process specifically includes the following steps.

S201: A coordinator node obtains a generated data block, determines adata node corresponding to the data block based on a block hash value ofthe data block, allocates the data block to the corresponding data node,creates routing information between the data block and the data node,and saves the routing information and block header information of thedata block.

There are generally multiple data nodes in the database system. For thisreason, the coordinator node first needs to determine which data nodethat a data block should be allocated to. Specifically, the coordinatornode can perform the allocation based on a hash value of the data block.

As described above, the hash value of the data block can be obtainedthrough calculation based on both a parent hash and a hash of a datarecord of the data block, and can be stored in a block header. Hashvalues (hash values) are obtained by using a hash function (hashfunction). Supported algorithms include MACTripleDES, MD5, RIPEMD160,SHA1, SHA256, SHA384, and SHA512, etc. In short, a block hash value of adata block is a relatively short string, and can uniquely identify thedata block. A small change to any content in the data block causes alarge change to the hash value of the data block.

A quantity of data nodes is generally fixed, and each data node cancorrespond to a serial number. Therefore, the hash value can beconverted into a corresponding numerical value, and a modulo operationcan be performed on the quantity of data nodes. As such, the data nodecorresponding to the data block can be determined based on a moduloresult.

For example, if a block hash value of a data block is converted into anumerical value 100110120, and there are totally 10 data nodes numberedfrom 0 to 9, it can be determined that a modulo result for the blockhash value is 0, tree node 0 is a data node corresponding to the blockhash value, and the data block can be sent to data node 0 for storage.

Because a block hash value of a data block generally has hundreds ofplaces (a quantity of places is determined based on a hash algorithm), aspecified quantity of places (for example, last three places) can beselected from the block hash value for numerical value conversion, sothat a modulo operation can be performed to determine a data nodecorresponding to the data block, thereby reducing a calculation amount.

For another example, all data nodes can also be arranged on anend-to-end hash ring, for example, a hash ring with a size from 0 to2{circumflex over ( )}32. Each node can be located at a certain point onthe hash ring based on a hash value corresponding to an address or adevice identifier of the data node. Each block hash value can be locatedat a certain location on the hash ring based on the same principle, sothat a data node appearing first in a clockwise or counterclockwisedirection can be used as a data node corresponding to the block hashvalue.

After a data node corresponding to a data block is determined, a pieceof routing information related to the data block can be created andwritten into a routing table in the coordinator node. Specifically, arouting table can be locally stored and include information such as adata block height, a data block hash, and a data node serial numbercorresponding to a data block.

In addition, the coordinator node also needs to store block headerinformation of each data block in addition to storing the routinginformation.

S203: The data node receives and stores the data block sent by thecoordinator node.

In the solutions provided in the implementations of the presentapplication, a routing relationship between a data block and a data nodeis established by using a block hash of the data block, ablockchain-type ledger is stored in a distributed manner at a level ofgranularity of data block, and metadata such as block header informationis stored in a coordinator node. As such, storage load of a single nodedevice can be reduced, and it is conducive to performing operations suchas query and verification through multiple processes, thereby improvingefficiency and bringing more convenience.

For example, assume that there are N data nodes, and data blocks areapproximately evenly distributed on the data nodes. According to thesolutions provided in the implementations of the present specification,when full verification needs to be performed on a ledger, data blockinternal verification can be allocated to the N data nodes forimplementation, which is N times more efficient than conventional serialverification performed from beginning to end.

In a target data node, a data block identifier can be a block heightincluded in a block header or a data block hash. In an implementation,the coordinator node can further send only a block body of a data blockand an identifier to a data node. In this case, the data node can onlyneed to store the block body, the block body identifier, and informationused for verification. There can be multiple types of data blockidentifiers, for example, a block height of a data block, and/or a blockhash of a data block. In such a method, the routing information in thecoordinator node includes a block body identifier and a data node serialnumber. The previously mentioned method can reduce data transmissionoverheads of the coordinator node and save storage space of the datanode. The information used for verification refers to information usedto verify integrity of the data block, and can include a hash value ofthe data block and a hash value of a parent data block.

Based on the previously storage method, the database system can performparallel verification when receiving a verification instructioninitiated by a user. FIG. 3 is a schematic flowchart illustrating a dataverification method, according to an implementation of the presentspecification. The method is applied to a database system that storesblockchain-type ledgers in a centralized manner. The database systemincludes a coordinator node and data nodes. The method includes thefollowing steps.

S301: The coordinator node receives a first verification instruction,and determines a target ledger that is to be verified, and performsblock header integrity verification on block headers of data blocks inthe target ledger based on block header information stored in thecoordinator node, where the target ledger includes a full ledger or apartial ledger (i.e., a segment of the full ledger).

The first verification instruction here can be an operation instructionentered by a user, for example, VERIFY(‘khash’,&v,−1). ‘khash’ is a hashvalue of a data block entered by the user. The system can determine acorresponding data block based on the hash value, so that all datablocks between the data block and “−1 data block” (that is, an initialdata block) can be used as the target ledger. For another example, auser can directly input block heights of specified data blocks:VERIFY(1,1000), so that the first 1000 data blocks can be used as thetarget ledger. For another example, a user can input specified timepoints VERIFY(T1,T2), so that data blocks generated between T1 and T2can serve as the target ledger and be verified. In addition, the targetledger can alternatively be a current full ledger.

The verification here refers to integrity verification. As describedabove, in the implementation of the present specification, because ahash value of a data block is obtained based on both a hash value of adata record of the data block and a hash value of a previous data block,any change to the data record can cause a change to the hash value ofthe data block.

Therefore, the user can initiate integrity verification at any time toverify whether a data block is complete or correct by verifying whethera block hash of the data block stored in a block header is correct. Aspecific method is as follows: Starting from the first data block of thetarget ledger according to a generation sequence, a block hash of acurrent data block is generated based on a block hash of a previous datablock and a root hash of a Merkle tree corresponding to a data record inthe data block, and the generated block hash is compared with a blockhash of the data block in pre-stored block header information. In theverification method at such a level of granularity, only the blockheader information is needed, and therefore the verification can beperformed only on the coordinator node that stores the block headerinformation.

S303: If the block header integrity verification succeeds, determine atarget data node corresponding to each data block in the target ledgerbased on routing information between a data block and a data node storedin the coordinator node.

If the verification based on the block header information fails, it isclear that no further verification is needed, and an integrityverification failure can be returned.

After the block header integrity verification succeeds, block bodyinternal integrity verification can be further performed. In thepreviously described storage method, specific data block information isnot stored in the coordinator node, but is distributed in the datanodes. Therefore, further verification work needs to be allocated.Specifically, as the target ledger includes multiple data blocks, andrelated routing information is created for each data block when the datablock is stored, a target data node corresponding to each data block canbe separately determined. For any data block, a target data node refersto a data node that stores the data block.

Based on pre-stored routing information, the coordinator node candetermined a specific data node that stores each data block. Therefore,multiple target data nodes can be separately determined, and themultiple target data nodes store all data blocks in the target ledger.

S305: Send a second verification instruction to the target data node,where the second verification instruction includes a data blockidentifier.

Further, for any determined target data node, the coordinator node cangenerate and send a corresponding second verification instruction. Eachsecond verification instruction includes a data block identifier. A datablock corresponding to the data block identifier should be stored in thetarget data node. The data block identifier can be a block height or ablock hash of the data block, and should have the same type as a datablock identifier stored in the data node.

In the previously described process, because there are multiple targetdata nodes, each data node receives one second verification instruction.

S307: The data node receives the second verification instruction,performs block body integrity verification on a data block correspondingto the data block identifier, generates a verification result, andreturns the verification result to the coordinator node.

After receiving the second verification instruction, any data node candetermine, based on the data block identifier, a data block that needsto be verified. A specific verification method is as follows: A hashvalue of each data record is obtained, a root hash value of a Merkletree of the data record in the data block is obtained throughcalculation, and further a hash value of the data block is obtainedthrough calculation based on a previously stored parent hash value, andis compared with a previously stored hash value of the data block. Ifthe calculated hash value of the data block is the same as thepreviously stored hash value of the data block, the verificationsucceeds, or otherwise the verification fails, and a verification resultis returned to the coordinator node.

S309: The coordinator node receives the verification result, anddetermines integrity of the target ledger.

The coordinator node can determine that the ledger is complete only whenall verification results indicate successful verification. If any resultindicates a verification failure, it can be determined that the ledgeris incomplete.

According to the solutions provided in the implementations of thepresent specification, when a blockchain-type ledger needs to beverified, integrity verification can be first performed on block headersin a coordinator node only, and after the verification succeeds, asecond verification instruction can be further distributed to datanodes, so that the data nodes perform data block internal verificationin parallel, thereby largely improving verification efficiency.

In an implementation, the coordinator node can further perform blockheader integrity verification based on a time service certificategenerated by a time authority. The time service certificate can begenerated in advance in the following way: The coordinator nodedetermines a target ledger that needs time service authentication, wherethe target ledger includes at least one data block or multiple datablocks with consecutive block heights; generates a Merkle treecorresponding to the target ledger based on a sequence of block heightsof data blocks in the target ledger, and determines a root hash of theMerkle tree based on a block hash of each data block; sends the roothash of the Merkle tree and related information of the data blocks to atime authority, where the related information of the data blocksincludes a start block height, an end block height, or a quantity of thedata blocks; and receives a time service certificate that is returned bythe time authority, where the time service certificate corresponds tothe target ledger and includes a trusted timestamp and a time authoritysignature. The time service certificate can include a start data blockheight, an end data block height, a trusted timestamp, and a root hashof a partial ledger.

In other words, a time service certificate is used to confirm that ageneration time of a segment of ledger is before a timestamp given bythe time authority. For example, the time authority can be the NationalTime Service Center or a related time service institution authorized bythe National Time Service Center.

The first verification instruction can include a time point or a timeinterval determined by two time points. The coordinator node can performmatching based on the time point in the first verification instructionand the trusted timestamp in the time service certificate. For example,when the first verification instruction includes one time point, acorresponding time service certificate can be a time service certificatewith a minimum time interval between a trusted timestamp and the timepoint. When the first verification instruction includes a time intervaldetermined by two time points, corresponding time service certificatescan be all time service certificates with trusted timestamps fallinginto the time interval.

During block header integrity verification based on a time servicecertificate, a data block range for verification is determined by astart block height and an end block height that are included in the timeservice certificate. A verification method is as follows: constructing aMerkle tree from a start block height to an end block height,calculating a root hash, and comparing the calculated root hash with aroot hash in the time service certificate.

When there are multiple time service certificates, block headerintegrity verification can be performed on partial ledgers correspondingto the time service certificates based on a sequence of trustedtimestamps in the time service certificates.

In another implementation, the coordinator node receives a fullverification instruction specific to a ledger. In this case, the fullverification instruction does not need to include a time point, and thecoordinator node can perform block header integrity verification on thefull ledger based on all time service certificates.

Notably, because a time service certificate is also stored in thecoordinator node, block header integrity verification based on a timeservice certificate can be performed only in the coordinator node, andno data node needs to be called.

In an implementation, before receiving the verification result returnedby the data node for the data block, the coordinator node can generatean integrity array in the coordinator node to record verificationresults provided by the data nodes for the data blocks in the targetledger. When generating the verification result, the data node canreturn a feature value that represents a failure or a success. Forexample, 1 is returned for a verification success, and 0 is returned fora verification failure. Therefore, a value of an element in theintegrity array is either 1 or 0. When a value of any element in theintegrity array is 0, the coordinator node can determine that theverification fails. When values of elements in the integrity array areall 1s, the coordinator node can determine that the verificationsucceeds. Statistical collection of verification results can be moreconvenient by recording a verification status of each data block in theintegrity array.

Correspondingly, an implementation of the present specification furtherprovides a data verification system, which is applied to a databasesystem that stores blockchain-type ledgers in a centralized manner. Thedatabase system includes a coordinator node and data nodes, where thecoordinator node receives a first verification instruction, anddetermines a target ledger that is to be verified, and performs blockheader integrity verification on block headers of data blocks in thetarget ledger based on block header information stored in thecoordinator node, where the target ledger includes a partial ledger or afull ledger; if the block header integrity verification succeeds, thecoordinator node determines a target data node corresponding to eachdata block in the target ledger based on routing information between adata block and a data node stored in the coordinator node; and thecoordinator node sends a second verification instruction to the targetdata node, where the second verification instruction includes a datablock identifier; the data node receives the second verificationinstruction, performs block body integrity verification on a data blockcorresponding to the data block identifier, generates a verificationresult, and returns the verification result to the coordinator node; andthe coordinator node receives the verification result, and determinesintegrity of the target ledger; where in the blockchain-type ledgers, adata block includes a block header used to store metadata and a blockbody used to store a data record; and except an initial data block, eachdata block includes at least one data record and includes its own blockhash value that is determined by both the data record included in thedata block and a hash value of a previous data block, and block heightsof data blocks are increased monotonically based on a block generationtime sequence.

Further, a data block is stored in advance in the database system in thefollowing way: obtaining, by the coordinator node, a generated datablock, determining a data node corresponding to the data block based ona block hash value of the data block, allocating the data block to thecorresponding data node, creating routing information between the datablock and the data node, and saving the routing information and blockheader information of the data block; and receiving and storing, by thedata node, the data block sent by the coordinator node.

Further, in the database system, the coordinator node obtains a blockheader and a block body in the data block, and allocates the block bodyto the corresponding data node; and correspondingly, the coordinatornode creates routing information between the block body and the datanode; and correspondingly, the data node receives the block body sent bythe coordinator node.

Further, a data block is generated in advance in the database system inthe following way: receiving a data record to be stored, and determininga hash value of each data record; and when a predetermined blockgeneration condition is reached, determining each data record to bewritten into a data block and generating the Nth data block thatincludes a hash value of the data block and the data record,specifically including: when N=1, giving a hash value and a block heightof the initial data block based on a predetermined method; and when N>1,determining the hash value of the Nth data block based on each datarecord to be written into the data block and a hash value of the (N−1)thdata block, and generating the Nth data block that includes the hashvalue of the Nth data block, each data record, and a block generationtime of the data block, where block heights of data blocks are increasedmonotonically based on a block generation time sequence.

Further, in the database system, the coordinator node receives a timepoint included in the first verification instruction, obtains a timeservice certificate corresponding to the time point, and determines apartial ledger corresponding to the time service certificate as thetarget ledger, where the time service certificate includes a start datablock height, an end data block height, a trusted timestamp, and a roothash of the corresponding partial ledger; and correspondingly, thecoordinator node performs block header integrity verification on thepartial ledger based on the time service certificate and the storedblock header information.

Further, in the database system, before the coordinator node receivesthe verification result, the coordinator node generates an integrityarray used to record verification results of the data blocks in thetarget ledger, where each element in the integrity array corresponds toone data block; and correspondingly, the data node generates theverification result, and returns the verification result to thecoordinator node by generating, by the data node, a feature value thatrepresents a verification failure or a verification success, andreturning the feature value to the coordinator node; andcorrespondingly, the coordinator node receives the verification result,and determines the integrity of the target ledger by determining thatthe target ledger is incomplete when a value of any element in theintegrity array is the feature value that represents a verificationfailure.

Correspondingly, an implementation of the present specification furtherprovides a data verification method, which is applied to a coordinatornode in a database system that stores blockchain-type ledgers in acentralized manner. FIG. 4 is a schematic flowchart illustrating a dataverification method applied to the coordinator node, according to animplementation of the present specification. The method includes thefollowing steps

S401: Receive a first verification instruction, and determine a targetledger that is to be verified, and perform block header integrityverification on block headers of data blocks in the target ledger basedon block header information stored in the coordinator node, where thetarget ledger includes a partial ledger or a full ledger.

S403: If the block header integrity verification succeeds, determine atarget data node corresponding to each data block in the target ledgerbased on routing information between a data block and a data node storedin the coordinator node.

S405: Send a second verification instruction to the target data node,where the second verification instruction includes a data blockidentifier.

S407: Receive a verification result returned by the target data node forthe data block, and determine integrity of the target ledger based onthe verification result.

In the blockchain-type ledgers, a data block includes a block headerused to store metadata and a block body used to store a data record; andexcept an initial data block, each data block includes at least one datarecord and includes its own block hash value that is determined by boththe data record included in the data block and a hash value of aprevious data block, and block heights of data blocks are increasedmonotonically based on a block generation time sequence.

Correspondingly, an implementation of the present specification furtherprovides a data verification apparatus, which is applied to acoordinator node in a database system that stores blockchain-typeledgers in a centralized manner. FIG. 5 is a schematic structuraldiagram illustrating a data verification apparatus applied to thecoordinator node, according to an implementation of the presentspecification. The apparatus includes the following: a block headerverification module 501, configured to receive a first verificationinstruction, and determine a target ledger that is to be verified, andperform block header integrity verification on block headers of datablocks in the target ledger based on block header information stored inthe coordinator node, where the target ledger includes a partial ledgeror a full ledger; a determining module 503, configured to, if the blockheader integrity verification succeeds, determine a target data nodecorresponding to each data block in the target ledger based on routinginformation between a data block and a data node stored in thecoordinator node; a sending module 505, configured to send a secondverification instruction to the target data node, where the secondverification instruction includes a data block identifier; and areceiving module 507, configured to receive a verification resultreturned by the target data node for the data block, and determineintegrity of the target ledger based on the verification result.

In the blockchain-type ledgers, a data block includes a block headerused to store metadata and a block body used to store a data record; andexcept an initial data block, each data block includes at least one datarecord and includes its own block hash value that is determined by boththe data record included in the data block and a hash value of aprevious data block, and block heights of data blocks are increasedmonotonically based on a block generation time sequence.

An implementation of the present specification further provides acomputer device. The computer device includes at least a memory, aprocessor, and a computer program that is stored in the memory and thatcan run on the processor. When executing the program, the processorperforms the data verification method shown in FIG. 4.

FIG. 6 is a more detailed schematic structural diagram illustrating ahardware structure of a computing device, according to an implementationof the present specification. The device can include a processor 1010, amemory 1020, an input/output interface 1030, a communications interface1040, and a bus 1050. The processor 1010, the memory 1020, theinput/output interface 1030, and the communications interface 1040 areconnected to and communicate with each other inside the device by usingthe bus 1050.

The processor 1010 can be implemented by using a general centralprocessing unit (CPU), a microprocessor, an application-specificintegrated circuit (ASIC), one or more integrated circuits, etc., and isconfigured to execute a related program, so as to implement thetechnical solutions provided in the implementations of the presentspecification.

The memory 1020 can be implemented by using a read-only memory (ROM), arandom access memory (RAM), a static storage device, a dynamic storagedevice, etc. The memory 1020 can store an operating system and anotherapplication program. When the technical solutions provided in theimplementations of the present specification are implemented by usingsoftware or firmware, related program code is stored in the memory 1020,and is called and executed by the processor 1010.

The input/output interface 1030 is configured to connect to aninput/output device, to input or output information. The input/outputdevice (not shown in the figure) can be used as a component andconfigured in the device, or can be externally connected to the device,to provide a corresponding function. The input device can include akeyboard, a mouse, a touchscreen, a microphone, various sensors, etc.The output device can include a display, a speaker, a vibrator, anindicator, etc.

The communications interface 1040 is configured to connect to acommunications module (not shown in the figure), to implementcommunication interaction between the device and another device. Thecommunications module can perform communication by using a wired (forexample, USB or a network cable) or wireless (for example, a mobilenetwork, Wi-Fi, or Bluetooth) method.

The bus 1050 includes one channel, used to transmit information betweencomponents (for example, the processor 1010, the memory 1020, theinput/output interface 1030, and the communications interface 1040) ofthe device.

Notably, although only the processor 1010, the memory 1020, theinput/output interface 1030, the communications interface 1040, and thebus 1050 of the device are shown, during specific implementation, thedevice can further include other components necessary for normalrunning. In addition, a person skilled in the art can understand thatthe device can include only components necessary for implementing thesolutions in the implementations of the present specification, but doesnot necessarily include all components shown in the figure.

An implementation of the present specification further provides acomputer readable storage medium. The computer readable storage mediumstores a computer program, and when executed by a processor, the programcan implement the data verification method shown in FIG. 4.

The computer readable medium includes persistent, non-persistent,movable, and unmovable media that can store information by using anymethod or technology. The information can be a computer readableinstruction, a data structure, a program module, or other data. Examplesof the computer storage medium include but are not limited to a phasechange random access memory (PRAM), a static RAM (SRAM), a dynamic RAM(DRAM), a RAM of another type, a read-only memory (ROM), an electricallyerasable programmable ROM (EEPROM), a flash memory or another memorytechnology, a compact disc ROM (CD-ROM), a digital versatile disc (DVD),or another optical storage, a cassette, a cassette magnetic diskstorage, or another magnetic storage device or any othernon-transmission medium. The computer storage medium can be configuredto store information that can be accessed by a computing device. Asdescribed in the present specification, the computer readable mediumdoes not include computer readable transitory media (transitory media)such as a modulated data signal and a carrier.

It can be seen from the previous descriptions of the implementationsthat, a person skilled in the art can clearly understand that theimplementations of the present specification can be implemented by usingsoftware and a necessary general hardware platform. Based on such anunderstanding, the technical solutions in the implementations of thepresent specification essentially or the part contributing to theexisting technology can be implemented in a form of a software product.The computer software product can be stored in a storage medium, such asa ROM/RAM, a magnetic disk, or an optical disc, and includes severalinstructions for instructing a computer device (which can be a personalcomputer, a server, a network device, etc.) to perform the methoddescribed in the implementations of the present specification or in someparts of the implementations of the present specification.

The system, method, module, or unit illustrated in the previousimplementations can be implemented by using a computer chip or anentity, or can be implemented by using a product having a certainfunction. A typical implementation device is a computer, and thecomputer can be a personal computer, a laptop computer, a cellularphone, a camera phone, a smartphone, a personal digital assistant, amedia player, a navigation device, an email receiving and sendingdevice, a game console, a tablet computer, a wearable device, or anycombination of these devices.

The implementations in the present specification are described in aprogressive way. For same or similar parts of the implementations,references can be made to the implementations mutually. Eachimplementation focuses on a difference from other implementations.Particularly, an apparatus implementation is similar to a methodimplementation, and therefore is described briefly. For a related part,references can be made to some descriptions in the methodimplementation. The previously described apparatus implementations aremerely examples. The modules described as separate parts can or cannotbe physically separate. During implementation of the solutions in theimplementations of the present specification, functions of the modulescan be implemented in one or more pieces of software and/or hardware.Some or all of the modules can be selected based on an actual need toimplement the solutions of the implementations. A person of ordinaryskill in the art can understand and implement the implementations of thepresent specification without creative efforts.

The previous descriptions are merely specific implementations of theimplementations of the present specification. It should be noted that aperson of ordinary skill in the art can further make severalimprovements or polishing without departing from the principle of theimplementations of the present specification, and the improvements orpolishing shall fall within the protection scope of the implementationsof the present specification.

1.-20. (canceled)
 21. A computer-implemented method for dataverification, comprising: receiving, by a coordinator node in a databasesystem that stores data in blockchain-type ledgers in a centralizedmanner, a first verification instruction, wherein the database systemcomprises the coordinator node and one or more data nodes; determining,by the coordinator node and based on the first verification instruction,a target ledger that is to be verified, wherein the target ledgercomprises a blockchain-type ledger that stores a plurality of datablocks, wherein in the blockchain-type ledger, each data block of theplurality of data blocks comprises a corresponding block header used tostore corresponding metadata and a corresponding block body used tostore corresponding data records, and wherein except an initial datablock, each data block of the plurality of data blocks comprises atleast one data record and a corresponding hash value that is determinedby both the at least one data record and a hash value of a previous datablock; performing, by the coordinator node and based on block headerinformation stored in the coordinator node, block header integrityverification on block headers of the plurality of data blocks in thetarget ledger, wherein the block header information comprisesinformation of the corresponding block header of each data block of theplurality of data blocks in the target ledger, and wherein performingthe block header integrity verification on the block headers of theplurality of data blocks in the target ledger comprises comparing a hashvalue of a data block of the plurality of data blocks in the blockheader information with a hash value generated using data recordsassociated with the data block of the plurality of data blocks;determining, by the coordinator node, that the block header integrityverification fails; and in response to determining that the block headerintegrity verification fails: refraining, by the coordinator node, fromfurther integrity verification of the target ledger; and generating, bythe coordinator node, an indicator indicating that integrity of thetarget ledger has been compromised.
 22. The computer-implemented methodaccording to claim 21, further comprising: determining, by thecoordinator node and based on the first verification instruction, asecond target ledger that is to be verified, wherein the second targetledger comprises a second blockchain-type ledger that stores a secondplurality of data blocks, wherein in the second blockchain-type ledger,each data block of the second plurality of data blocks comprises arespective block header used to store respective metadata and arespective block body used to store respective data records; and whereinexcept an initial data block of the second plurality of data blocks,each data block of the second plurality of data blocks comprises atleast one respective data record and a respective hash value that isdetermined by both the at least one respective data record comprised ineach data block of the second plurality of data blocks and a hash valueof a previous data block of the second plurality of data blocks;performing, by the coordinator node and based on second block headerinformation stored in the coordinator node, second block headerintegrity verification on block headers of the second plurality of datablocks in the second target ledger, wherein the second block headerinformation comprises information of the respective block header of eachdata block of the second plurality of data blocks in the second targetledger, and wherein performing the second block header integrityverification on the block headers of the second plurality of data blocksin the second target ledger comprises comparing a hash value of a datablock of the second plurality of data blocks in the second block headerinformation with a hash value generated using data records associatedwith the data block of the second plurality of data blocks; determining,by the coordinator node, that the second block header integrityverification succeeds; and in response to determining that the secondblock header integrity verification succeeds: determining, by thecoordinator node and for each data block of the second plurality of datablocks in the second target ledger, a corresponding target data node inthe database system based on routing information stored in thecoordinator node, wherein the routing information comprises mappingrelationship between each data block of the second plurality of datablocks in the second target ledger and a corresponding data node in thedatabase system; sending, by the coordinator node and to each targetdata node in the database system, a corresponding second verificationinstruction, wherein each target data node stores a corresponding datablock of the second plurality of data blocks in the second targetledger, and wherein the corresponding second verification instructioncomprises a corresponding data block identifier associated with thecorresponding data block of the second plurality of data blocks in thesecond target ledger; receiving, by the coordinator node and from eachtarget data node, a corresponding verification result, wherein eachtarget data node is associated with the corresponding secondverification instruction, wherein the corresponding verification resultis of block body integrity verification on a data block corresponding toa data block identifier comprised in the corresponding secondverification instruction; and determining, by the coordinator node, theintegrity of the target ledger based on the corresponding verificationresult received from each target data node.
 23. The computer-implementedmethod according to claim 21, wherein each data block of the pluralityof data blocks in the target ledger is stored in advance in the databasesystem by: obtaining, by the coordinator node, each data block of theplurality of data blocks in the target ledger; determining, by thecoordinator node, a corresponding data node in the database systemcorresponding to each data block based on the corresponding hash valueof each data block; allocating, by the coordinator node, each data blockto the corresponding data node; creating, by the coordinator node,corresponding routing information between each data block and thecorresponding data node; saving, by the coordinator node, thecorresponding routing information between each data block and thecorresponding data node and block header information of each data block;and sending, by the coordinator node and to the corresponding data node,each data block to be stored by the corresponding data node.
 24. Thecomputer-implemented method according to claim 23, wherein allocating,by the coordinator node, each data block to the corresponding data nodecomprises: obtaining, by the coordinator node, the corresponding blockheader and the corresponding block body in each data block; andallocating, by the coordinator node, the corresponding block body to thecorresponding data node, wherein creating, by the coordinator node, thecorresponding routing information between each data block and thecorresponding data node comprises creating, by the coordinator node, thecorresponding routing information between the corresponding block bodyand the corresponding data node, and wherein sending, by the coordinatornode and to the corresponding data node, each data block to be stored bythe corresponding data node comprises sending, by the coordinator nodeand to the corresponding data node, the corresponding block body to bestored by the corresponding data node.
 25. The computer-implementedmethod according to claim 23, wherein each data block is generated inadvance in the database system by: receiving data records to be writtenin an Nth data block; determining a hash value of the data records; andif a predetermined block generation condition is reached, determiningthe data records; and generating the Nth data block that comprises thedata records and the hash value of the data records, wherein generatingthe Nth data block that comprises the data records and the hash value ofthe data records comprises: if N=1, setting a hash value and a blockheight of the initial data block based on a predetermined methodology;and if N>1, determining a hash value of the Nth data block based on thedata records to be written into the Nth data block and a hash value of a(N−1)th data block; and generating the Nth data block that comprises thehash value of the Nth data block, the data records to be written intothe Nth data block, and a block generation time of the Nth data block.26. The computer-implemented method according to claim 21, whereinreceiving the first verification instruction, and determining the targetledger comprises: receiving a time point comprised in the firstverification instruction; obtaining a time service certificatecorresponding to the time point; and determining a partial ledgercorresponding to the time service certificate as the target ledger,wherein the time service certificate comprises a start data blockheight, an end data block height, a trusted timestamp, and a root hashof the partial ledger, and wherein performing the block header integrityverification on the block headers of the plurality of data blocks in thetarget ledger based on the block header information stored in thecoordinator node comprises performing the block header integrityverification on the partial ledger based on the time service certificateand the block header information.
 27. The computer-implemented methodaccording to claim 22, wherein before receiving the correspondingverification result from each target data node, the computer-implementedmethod further comprises: generating, by the coordinator node, anintegrity array comprising verification results of the second pluralityof data blocks in the second target ledger, wherein each element in theintegrity array corresponds to a respective data block of the secondplurality of data blocks in the second target ledger, wherein thecorresponding verification result from each target data node comprises acorresponding feature value that comprises one of a verification failureand a verification success, and wherein the determining, by thecoordinator node, the integrity of the second target ledger based on thecorresponding verification result received from each target data nodecomprises determining, by the coordinator node, that the second targetledger is incomplete if a value of an element in the integrity arraycomprises a feature value that comprises a verification failure.
 28. Anon-transitory, computer-readable medium storing one or moreinstructions executable by a computer system to perform operationscomprising: receiving, by a coordinator node in a database system thatstores data in blockchain-type ledgers in a centralized manner, a firstverification instruction, wherein the database system comprises thecoordinator node and one or more data nodes; determining, by thecoordinator node and based on the first verification instruction, atarget ledger that is to be verified, wherein the target ledgercomprises a blockchain-type ledger that stores a plurality of datablocks, wherein in the blockchain-type ledger, each data block of theplurality of data blocks comprises a corresponding block header used tostore corresponding metadata and a corresponding block body used tostore corresponding data records, and wherein except an initial datablock, each data block of the plurality of data blocks comprises atleast one data record and a corresponding hash value that is determinedby both the at least one data record and a hash value of a previous datablock; performing, by the coordinator node and based on block headerinformation stored in the coordinator node, block header integrityverification on block headers of the plurality of data blocks in thetarget ledger, wherein the block header information comprisesinformation of the corresponding block header of each data block of theplurality of data blocks in the target ledger, and wherein performingthe block header integrity verification on the block headers of theplurality of data blocks in the target ledger comprises comparing a hashvalue of a data block of the plurality of data blocks in the blockheader information with a hash value generated using data recordsassociated with the data block of the plurality of data blocks;determining, by the coordinator node, that the block header integrityverification fails; and in response to determining that the block headerintegrity verification fails: refraining, by the coordinator node, fromfurther integrity verification of the target ledger; and generating, bythe coordinator node, an indicator indicating that integrity of thetarget ledger has been compromised.
 29. The non-transitory,computer-readable medium according to claim 28, wherein the operationsfurther comprise: determining, by the coordinator node and based on thefirst verification instruction, a second target ledger that is to beverified, wherein the second target ledger comprises a secondblockchain-type ledger that stores a second plurality of data blocks,wherein in the second blockchain-type ledger, each data block of thesecond plurality of data blocks comprises a respective block header usedto store respective metadata and a respective block body used to storerespective data records; and wherein except an initial data block of thesecond plurality of data blocks, each data block of the second pluralityof data blocks comprises at least one respective data record and arespective hash value that is determined by both the at least onerespective data record comprised in each data block of the secondplurality of data blocks and a hash value of a previous data block ofthe second plurality of data blocks; performing, by the coordinator nodeand based on second block header information stored in the coordinatornode, second block header integrity verification on block headers of thesecond plurality of data blocks in the second target ledger, wherein thesecond block header information comprises information of the respectiveblock header of each data block of the second plurality of data blocksin the second target ledger, and wherein performing the second blockheader integrity verification on the block headers of the secondplurality of data blocks in the second target ledger comprises comparinga hash value of a data block of the second plurality of data blocks inthe second block header information with a hash value generated usingdata records associated with the data block of the second plurality ofdata blocks; determining, by the coordinator node, that the second blockheader integrity verification succeeds; and in response to determiningthat the second block header integrity verification succeeds:determining, by the coordinator node and for each data block of thesecond plurality of data blocks in the second target ledger, acorresponding target data node in the database system based on routinginformation stored in the coordinator node, wherein the routinginformation comprises mapping relationship between each data block ofthe second plurality of data blocks in the second target ledger and acorresponding data node in the database system; sending, by thecoordinator node and to each target data node in the database system, acorresponding second verification instruction, wherein each target datanode stores a corresponding data block of the second plurality of datablocks in the second target ledger, and wherein the corresponding secondverification instruction comprises a corresponding data block identifierassociated with the corresponding data block of the second plurality ofdata blocks in the second target ledger; receiving, by the coordinatornode and from each target data node, a corresponding verificationresult, wherein each target data node is associated with thecorresponding second verification instruction, wherein the correspondingverification result is of block body integrity verification on a datablock corresponding to a data block identifier comprised in thecorresponding second verification instruction; and determining, by thecoordinator node, the integrity of the target ledger based on thecorresponding verification result received from each target data node.30. The non-transitory, computer-readable medium according to claim 28,wherein each data block of the plurality of data blocks in the targetledger is stored in advance in the database system by: obtaining, by thecoordinator node, each data block of the plurality of data blocks in thetarget ledger; determining, by the coordinator node, a correspondingdata node in the database system corresponding to each data block basedon the corresponding hash value of each data block; allocating, by thecoordinator node, each data block to the corresponding data node;creating, by the coordinator node, corresponding routing informationbetween each data block and the corresponding data node; saving, by thecoordinator node, the corresponding routing information between eachdata block and the corresponding data node and block header informationof each data block; and sending, by the coordinator node and to thecorresponding data node, each data block to be stored by thecorresponding data node.
 31. The non-transitory, computer-readablemedium according to claim 30, wherein allocating, by the coordinatornode, each data block to the corresponding data node comprises:obtaining, by the coordinator node, the corresponding block header andthe corresponding block body in each data block; and allocating, by thecoordinator node, the corresponding block body to the corresponding datanode, wherein creating, by the coordinator node, the correspondingrouting information between each data block and the corresponding datanode comprises creating, by the coordinator node, the correspondingrouting information between the corresponding block body and thecorresponding data node, and wherein sending, by the coordinator nodeand to the corresponding data node, each data block to be stored by thecorresponding data node comprises sending, by the coordinator node andto the corresponding data node, the corresponding block body to bestored by the corresponding data node.
 32. The non-transitory,computer-readable medium according to claim 30, wherein each data blockis generated in advance in the database system by: receiving datarecords to be written in an Nth data block; determining a hash value ofthe data records; and if a predetermined block generation condition isreached, determining the data records; and generating the Nth data blockthat comprises the data records and the hash value of the data records,wherein generating the Nth data block that comprises the data recordsand the hash value of the data records comprises: if N=1, setting a hashvalue and a block height of the initial data block based on apredetermined methodology; and if N>1, determining a hash value of theNth data block based on the data records to be written into the Nth datablock and a hash value of a (N−1)th data block; and generating the Nthdata block that comprises the hash value of the Nth data block, the datarecords to be written into the Nth data block, and a block generationtime of the Nth data block.
 33. The non-transitory, computer-readablemedium according to claim 28, wherein receiving the first verificationinstruction, and determining the target ledger comprises: receiving atime point comprised in the first verification instruction; obtaining atime service certificate corresponding to the time point; anddetermining a partial ledger corresponding to the time servicecertificate as the target ledger, wherein the time service certificatecomprises a start data block height, an end data block height, a trustedtimestamp, and a root hash of the partial ledger, and wherein performingthe block header integrity verification on the block headers of theplurality of data blocks in the target ledger based on the block headerinformation stored in the coordinator node comprises performing theblock header integrity verification on the partial ledger based on thetime service certificate and the block header information.
 34. Thenon-transitory, computer-readable medium according to claim 29, whereinbefore receiving the corresponding verification result from each targetdata node, the operations further comprises: generating, by thecoordinator node, an integrity array comprising verification results ofthe second plurality of data blocks in the second target ledger, whereineach element in the integrity array corresponds to a respective datablock of the second plurality of data blocks in the second targetledger, wherein the corresponding verification result from each targetdata node comprises a corresponding feature value that comprises one ofa verification failure and a verification success, and wherein thedetermining, by the coordinator node, the integrity of the second targetledger based on the corresponding verification result received from eachtarget data node comprises determining, by the coordinator node, thatthe second target ledger is incomplete if a value of an element in theintegrity array comprises a feature value that comprises a verificationfailure.
 35. A computer-implemented system, comprising: one or morecomputers; and one or more computer memory devices interoperably coupledwith the one or more computers and having tangible, non-transitory,machine-readable media storing one or more instructions that, whenexecuted by the one or more computers, perform one or more operationscomprising: receiving, by a coordinator node in a database system thatstores data in blockchain-type ledgers in a centralized manner, a firstverification instruction, wherein the database system comprises thecoordinator node and one or more data nodes; determining, by thecoordinator node and based on the first verification instruction, atarget ledger that is to be verified, wherein the target ledgercomprises a blockchain-type ledger that stores a plurality of datablocks, wherein in the blockchain-type ledger, each data block of theplurality of data blocks comprises a corresponding block header used tostore corresponding metadata and a corresponding block body used tostore corresponding data records, and wherein except an initial datablock, each data block of the plurality of data blocks comprises atleast one data record and a corresponding hash value that is determinedby both the at least one data record and a hash value of a previous datablock; performing, by the coordinator node and based on block headerinformation stored in the coordinator node, block header integrityverification on block headers of the plurality of data blocks in thetarget ledger, wherein the block header information comprisesinformation of the corresponding block header of each data block of theplurality of data blocks in the target ledger, and wherein performingthe block header integrity verification on the block headers of theplurality of data blocks in the target ledger comprises comparing a hashvalue of a data block of the plurality of data blocks in the blockheader information with a hash value generated using data recordsassociated with the data block of the plurality of data blocks;determining, by the coordinator node, that the block header integrityverification fails; and in response to determining that the block headerintegrity verification fails: refraining, by the coordinator node, fromfurther integrity verification of the target ledger; and generating, bythe coordinator node, an indicator indicating that integrity of thetarget ledger has been compromised.
 36. The computer-implemented systemaccording to claim 35, wherein the one or more operations furthercomprise: determining, by the coordinator node and based on the firstverification instruction, a second target ledger that is to be verified,wherein the second target ledger comprises a second blockchain-typeledger that stores a second plurality of data blocks, wherein in thesecond blockchain-type ledger, each data block of the second pluralityof data blocks comprises a respective block header used to storerespective metadata and a respective block body used to store respectivedata records; and wherein except an initial data block of the secondplurality of data blocks, each data block of the second plurality ofdata blocks comprises at least one respective data record and arespective hash value that is determined by both the at least onerespective data record comprised in each data block of the secondplurality of data blocks and a hash value of a previous data block ofthe second plurality of data blocks; performing, by the coordinator nodeand based on second block header information stored in the coordinatornode, second block header integrity verification on block headers of thesecond plurality of data blocks in the second target ledger, wherein thesecond block header information comprises information of the respectiveblock header of each data block of the second plurality of data blocksin the second target ledger, and wherein performing the second blockheader integrity verification on the block headers of the secondplurality of data blocks in the second target ledger comprises comparinga hash value of a data block of the second plurality of data blocks inthe second block header information with a hash value generated usingdata records associated with the data block of the second plurality ofdata blocks; determining, by the coordinator node, that the second blockheader integrity verification succeeds; and in response to determiningthat the second block header integrity verification succeeds:determining, by the coordinator node and for each data block of thesecond plurality of data blocks in the second target ledger, acorresponding target data node in the database system based on routinginformation stored in the coordinator node, wherein the routinginformation comprises mapping relationship between each data block ofthe second plurality of data blocks in the second target ledger and acorresponding data node in the database system; sending, by thecoordinator node and to each target data node in the database system, acorresponding second verification instruction, wherein each target datanode stores a corresponding data block of the second plurality of datablocks in the second target ledger, and wherein the corresponding secondverification instruction comprises a corresponding data block identifierassociated with the corresponding data block of the second plurality ofdata blocks in the second target ledger; receiving, by the coordinatornode and from each target data node, a corresponding verificationresult, wherein each target data node is associated with thecorresponding second verification instruction, wherein the correspondingverification result is of block body integrity verification on a datablock corresponding to a data block identifier comprised in thecorresponding second verification instruction; and determining, by thecoordinator node, the integrity of the target ledger based on thecorresponding verification result received from each target data node.37. The computer-implemented system according to claim 35, wherein eachdata block of the plurality of data blocks in the target ledger isstored in advance in the database system by: obtaining, by thecoordinator node, each data block of the plurality of data blocks in thetarget ledger; determining, by the coordinator node, a correspondingdata node in the database system corresponding to each data block basedon the corresponding hash value of each data block; allocating, by thecoordinator node, each data block to the corresponding data node,wherein allocating, by the coordinator node, each data block to thecorresponding data node comprises: obtaining, by the coordinator node,the corresponding block header and the corresponding block body in eachdata block; and allocating, by the coordinator node, the correspondingblock body to the corresponding data node; creating, by the coordinatornode, corresponding routing information between each data block and thecorresponding data node, wherein creating, by the coordinator node, thecorresponding routing information between each data block and thecorresponding data node comprises: creating, by the coordinator node,the corresponding routing information between the corresponding blockbody and the corresponding data node; saving, by the coordinator node,the corresponding routing information between each data block and thecorresponding data node and block header information of each data block;and sending, by the coordinator node and to the corresponding data node,each data block to be stored by the corresponding data node, whereinsending, by the coordinator node and to the corresponding data node,each data block to be stored by the corresponding data node comprises:sending, by the coordinator node and to the corresponding data node, thecorresponding block body to be stored by the corresponding data node.38. The computer-implemented system according to claim 37, wherein eachdata block is generated in advance in the database system by: receivingdata records to be written in an Nth data block; determining a hashvalue of the data records; and if a predetermined block generationcondition is reached, determining the data records; and generating theNth data block that comprises the data records and the hash value of thedata records, wherein generating the Nth data block that comprises thedata records and the hash value of the data records comprises: if N=1,setting a hash value and a block height of the initial data block basedon a predetermined methodology; and if N>1, determining a hash value ofthe Nth data block based on the data records to be written into the Nthdata block and a hash value of a (N−1)th data block; and generating theNth data block that comprises the hash value of the Nth data block, thedata records to be written into the Nth data block, and a blockgeneration time of the Nth data block.
 39. The computer-implementedsystem according to claim 35, wherein receiving the first verificationinstruction, and determining the target ledger comprises: receiving atime point comprised in the first verification instruction; obtaining atime service certificate corresponding to the time point; anddetermining a partial ledger corresponding to the time servicecertificate as the target ledger, wherein the time service certificatecomprises a start data block height, an end data block height, a trustedtimestamp, and a root hash of the partial ledger, and wherein performingthe block header integrity verification on the block headers of theplurality of data blocks in the target ledger based on the block headerinformation stored in the coordinator node comprises performing theblock header integrity verification on the partial ledger based on thetime service certificate and the block header information.
 40. Thecomputer-implemented system according to claim 36, wherein beforereceiving the corresponding verification result from each target datanode, the one or more operations further comprises: generating, by thecoordinator node, an integrity array comprising verification results ofthe second plurality of data blocks in the second target ledger, whereineach element in the integrity array corresponds to a respective datablock of the second plurality of data blocks in the second targetledger, wherein the corresponding verification result from each targetdata node comprises a corresponding feature value that comprises one ofa verification failure and a verification success, and wherein thedetermining, by the coordinator node, the integrity of the second targetledger based on the corresponding verification result received from eachtarget data node comprises determining, by the coordinator node, thatthe second target ledger is incomplete if a value of an element in theintegrity array comprises a feature value that comprises a verificationfailure.